home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 14951 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.2 KB
  1. Path: mayne.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c,comp.unix.programmer
  4. Subject: Re: Q: '\n' character
  5. Date: 15 Apr 1996 16:14:20 -0700
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4kul8cINNeni@mayne.ugrad.cs.ubc.ca>
  8. References: <4kj66f$k0o@ren.cei.net> <4kmdsv$ojc@masala.cc.uh.edu> <4kmhpsINN7ak@keats.ugrad.cs.ubc.ca> <4ku99k$4ub@dawn.mmm.com>
  9. NNTP-Posting-Host: mayne.ugrad.cs.ubc.ca
  10.  
  11. In article <4ku99k$4ub@dawn.mmm.com>, Chris Sonnack <cjsonnack@mmm.com> wrote:
  12. >Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
  13. >
  14. >> Oops, I didn't notice that.
  15. >
  16. >Which, by your standards, enables us to call you all sorts of names, right?
  17. >
  18. >> So how is it right if it had undesired effects under certain conditions?
  19. >
  20. >Because sometimes you need a short, simple solution to a problem and can
  21. >pretty much guarentee "certain conditions" will not occur, or if they do,
  22. >catastrophic failure is okay in these rare cases. Not recommending this as
  23. >a way of working or designing, just pointing the potential DOES exist.
  24.  
  25. Yeah. Those short solutions are OK. I mean, when I type a for ... command to
  26. the bourne shell, I don't care about doing everything so that it will not fail
  27. no matter what the files are named! I know I don't have files that have spaces
  28. in them or look like command-line options or start with , so I'm not about do
  29. to:
  30.  
  31.     for x in * ; do command -- "$x" ; done
  32.  
  33. instead of
  34.  
  35.     for x in * ; do command $x ; done
  36.  
  37. But in posting a sample Bourne script to a Newsgroup, I'd obey every rule I
  38. could think of. Or even in committing it to a script file.
  39.  
  40. Then again, on c.l.c we are just more conscious of potential pitfalls, and are
  41. big on correctness. You can't decide for someone what level of solution is
  42. appropriate. It's not likely that some newbie is working on a safety-critical
  43. project, but I can't decide that on his behalf.
  44.  
  45. No matter what code you write, you can never know 100% where it will end up, or
  46. how you, or someone else, will try to use it.
  47.  
  48. >> And of course, *real* UNIX users don't put lines longer than 79 chars into
  49. >> a textfile anyway...
  50. >
  51. >Correct!  ;-> (I know I //never// do!!)
  52.  
  53. I'll be darned if I write lines of source longer than 79 columns.
  54.  
  55.  
  56. >> Humor me as to why it is necessary to retain a whole string of data just
  57. >> to then scan through it to find its length to remove the trailining
  58. >> newline, which was put there by a standard library function that already
  59. >> scanned the characters once to _find_ the newline in the first place.
  60. >
  61. >I found your solution was the most correct and elegant. In fact, it's a
  62. >very nice solution and you did solve the original problem in the best
  63. >way it could be solved.
  64.  
  65. Well, almost.
  66.  
  67. There are many unknowns: there is likely much more to the original problem than
  68. was specified in the posting. The program could well _require_ that the lines
  69. be retained in a buffer for some purpose that wasn't stated, in which case the
  70. simple filter is useless. But so is a solution that sets an arbitrary buffer
  71. size limit. A good program will read in a line of any size, and do something
  72. reasonable with null characters. One poster just contributed a universal ``get
  73. line'' routine that dynamically allocates the buffer, and can increase the size
  74. to read in any line. I think I will go back and do a thorough (though
  75. constructive) critique to look for anything troublesome that would take away
  76. from its generality. It's a good candidate for inclusion in the c.l.c. FAQ.
  77.  
  78. It's programming like that which allows me to load a kernel image into the Vim
  79. editor, change a few bytes, and boot the result.  Whereas SVR4 vi will choke
  80. due to its arbitrary limitations (Maximum 1024 characters per line? Groan...)
  81.  
  82. >Doesn't change the fact that you're still rather a jerk.
  83.  
  84. I just don't like it when dilettantes play expert on a world-wide newsgroup.
  85. Especially when they are UNIX guys---that makes me look bad. I've seen and
  86. heard people criticize UNIX for some of its old broken programs and security
  87. holes stemming from sloppy programming. Some of the attitudes behind this
  88. programming apparently prevail to this day.
  89.  
  90. In any case, read my new temporary .sig
  91. -- 
  92. I'm not really a jerk, but I play one on Usenet.
  93.